Please type a plus sign (+) inside this box , 




rn PT0/SB/2I (6/98) 

' ' Approved for use through 9/30/2000. 0MB 065 1 -003 1 

Patent and Trademark Office; U.S. DEPARTMENT OF COMMERCE 
Paperwork Reduction Act of 1995, no persons are required to respond to a collection of information unless it displays a valid 0MB control number. 



NSMITTAL 
FORM 



(To be used for all correspondence after initial filing) 



Total Number of Pages in this Submission: 32 



Application No. 



Filing Date 



First Named Inventor 



Group Art Unit 



Examiner Name 



Attorney Docket No. 



09/901,954 



T 



July 10, 2001 



James Templeton 



3628 



Nga B. Nguyen 



PAYOO-003 



□ 

□ 
□ 
□ 
□ 
□ 



Fee Transmittal Form 
Fee attached 

Amendment/Response 
I I After Final 

I I Affidavit/Declaration(s) 

Extension of Time Request 

Express Abandonment Request 

Infonmation Disclosure Statement 



Certified Copy of Priority 
Document{s) 

Response to Missing Parts Notice/ 
Incomplete Application 



□ 



Response to Missing Parts 
under 37 CFR1.52 or 1.53 



ENCLOSURES {check all that applyj 



□ 
□ 

□ 
□ 
□ 

□ 

□ 
□ 
□ 

□ 



Assignment Papers for an application 
Drawing(s) 

Licensing-related Papers 
Petition 

Petition to Convert to a 
Provisional Application 

Power of Attorney by Assignee, with 
Revocation of Fomrier Powers 

Change of Correspondence Address 
Terminal Disclaimer 
Small Entity Statement 
Request for Refund 



□ 

□ 

□ 
□ 



After-Allowance Communication to 
Group 

Appeal Communication to Board of 
Appeals and Interferences 

Appeal Communication to Group 
{Appeal Notice, Brief, Reply Brief) 



Proprietary Infomiation 
Status Letter 
Additional Enclosure(s): 
^ Return Receipt Postcard 



I I Check for $ 

^ Credit Card Payment Fomi 



Remarks: 



SIGNATURE OF APPLICANT, ATTORNEY OR AGENT 



Name 



Signature 



Daniel E. Vaughan 




egistration No. 42,199) 



Address 39180 Liberty Street, Suite 103, Fremont, CA 94538 



Date 



Telephone 



Facsimile 



May 11,2006 



510-790-9960 



510-790-9964 



CERTIFICATE OF MAILING 



I hereby certify that this correspondence is being deposited with the U. S, Postal Service as |2Sl Express Mail (No. EV 716 586 959 US) or 
n First Class Mail in an envelope addressed to: Commissioner for Patents, P.O. Box 1450, Alexandria, VA 22313 on: May 1 1 . 2006 



Type or Printed Name 



Daniel E. Vaughan 



Signature 



Burden Hour Statement: This form is estimated to take 0.2 hours to complete. Time will vary depending upon the needs of the individual case. Any 
comments on the amount of time you are required to complete this form should be sent to the Chief Information Officer, Patent and Trademark Office 
Washington, DC 20231. DO NOT SEND FEES OR COMPLETED FORMS TO THIS ADDRESS. SEND TO: Assistant Commissioner for Patents' 
Washington, EX 20231. 




PTO/SB/17(12-04v2) 
Approved for use through 07/31/2006. OMB 0651-0032 
U.S. Patent and Trademark Office; U.S. DEPARTMENT OF COMMERCE 
inftrwnrk Rftriiirtinn Ant nf iflflS nn nfirsnns ara rpniiirftfl tn rfisnnnrt tn a mllftrtinn of infnrmatinn imlftR.*; it disnlavs a valirl OMR mntrnl niimher 



Effective on 12/08/2004. 
\ant to the Consolidated Appropriations Act. 2005 (H.R, 4818). 

EE TRANSMITTAL 

For FY 2005 



n Applicant claims smalt entity status. See 37 CFR 1 .27 



yJOTAL AMOUNT OF PAYMENT 



($) 



500.00 



Complete if Known 



Application Number 



Filing Date 



First Named Inventor 



Examiner Name 



Art Unit 



Attorney Docket No. 



09/901,954 



July 10. 2001 



James E. Templeton 



Nga B. Nguyen 



3628 



PAYOO-003 



METHOD OF PAYMENT (check all that apply) 



□ 
0 



Check Credit Card [ZD Money Order I I None I I 
Deposit Account Deposit Account Number: 50-1801 



Other (please identify): 

Deposit Account Name: Park. Vauahan & Fleming 



For the above-identified deposit account, the Director is hereby authorized to: (check al! that apply) 
Q Charge fee(s) indicated below Q Charge fee(s) indicated below, except for the filing fee 

HCharge any additional fee(s) or underpayments of fee(s) [/] credit any overpayments 
under 37 CFR 1.16 and 1.17 ' — ' ' ' 

WARNING: Information on this form may become public. Credit card information should not be included on this form. Provide credit card 
information and authorization on PTO-2038. 



FEE CALCULATION 



1. BASIC FILING. SEARCH, AND EXAMINATION FEES 



Application Tvpe 

Utility 

Design 

Plant 

Reissue 

Provisional 



FILING FEES 

Small Entity 
Feetf) 



Fee ($) 

300 
200 
200 
300 
200 



SEARCH FEES 

Small Entity 
Fee ($) 



150 
100 
100 
150 
100 



FeeiSl 

500 
100 
300 
500 
0 



EXAMINATION FEES 
Small Entity 
Feei$.) 



250 
50 
150 
250 
0 



Feeia 

200 
130 
160 
600 
0 



Fees Paid ($^ 



2. 



EXCESS CLAIM FEES 
Fee Description 

Each claim over 20 (including Reissues) 
Each independent claim over 3 (including Reissues) 
Multiple dependent claims 
Total Claims Extra Claims Fee ($) Fee Paid f$) 

43 - 20 or HP = 0 x = Q 

HP = highest number of total claims paid for, if greater than 20. 
Indep. Claims Extra Claims Fee ($) 
7 - 3 or HP = Q x 



100 

65 

80 

300 

0 

Small Entity 
Fee ($) Fee ($) 
50 25 
200 100 
360 180 
Multiple Dependent Claims 
Fee ($) Fee Paid ($) 



Fee Paid ($) 
_Q 



HP = highest number of independent claims paid for, if greater than 3. 

3. APPLICATION SIZE FEE 

If the specification and draw^ings exceed 100 sheets of paper (excluding electronically filed sequence or computer 
listings under 37 CFR 1.52(e)), the application size fee due is $250 ($125 for small entity) for each additional 50 
sheets or fraction thereof. See 35 U.S.C. 41(a)(1)(G) and 37 CFR 1.16(s). 

Total Sheets Extra Sheets Number of each additional 50 or Traction thereof Fee ($) Fee Paid ($) 

- 100 = / 50 = (round up to a whole number) x = 

4. OTHER FEE(S) 

Non-English Specification, $130 fee (no small entity discount) 

Other (e.g., late filing surcharge): Appeal Brief 



Fees Paid f$> 



$500.00 



SUBMITTED BY 



z. Vaughan U 



Signature 



Registration No. 
(Attorney/Agent) 



42,199 



Telephone 0.790-9960 



Name (Print/Type) 



Daniel E. Vaughai 



Date May 11,2006 



This collection of information is required by 37 CFR 1 .136. The information is, required to obtain or retain a benefit by the public which is to file (and by the 
USPTOto process) an application. Confidentiality is governed by 35 U.S.C. 122 and 37 CFR 1.14. This collection is estimated to take 30 minutes to complete, 
including gathering, preparing, and submitting the completed application form to the USPTO. Time will vary depending upon the individual case. Any comments 
on the amount of time you require to complete this form and/or suggestions for reducing this burden, should be sent to the Chief Information Officer, U.S. Patent 
and Trademark Office, U.S. Department of Commerce, P.O. Box 1450, Alexandria, VA 22313-1450. DO NOT SEND FEES OR COMPLETED FORMS TO THIS 
ADDRESS. SEND TO: Commissioner for Patents, P.O. Box 1450, Alexandria, VA 22313-1450. 

If you need assistance in completing the form, call 1-800'PTO'9199 and select option 2. 



m 1 



IN THE UNITED STATES PATENT AND TRADEMARK OFFICE 



Application No. 
Filed 

First Named Inventor 

Docket 

Title 



Group/ Art Unit 
Examiner 



09/90 1,954 Confirmation Number: 7267 

July 10, 2001 
James Templeton 
PAYOO-003 

System and Method for Verifying a Financial 
Instrument 

3628 

Nga B. Nguyen 



APPEAL BRIEF 
IN SUPPORT OF APPELLANT'S APPEAL 
TO THE BOARD OF PATENT APPEALS AND INTERFERENCES 



Commissioner for Patents 
P.O. Box 1450 
Alexandria VA 22313-1450 

Sir: 

This brief is submitted in support of Applicant's Appeal from a Final 
Decision of the Examiner mailed 19 December 2005. Applicant respectfully 
requests consideration of this Appeal by the Board of Patent Appeals and 
Interferences. 



05/16/2006 SHflSSEHl 00000006 09901954 

01 FC:140e 500.00 OP 



TABLE OF CONTENTS 



I. REAL PARTY IN INTEREST 1 

IL RELATED APPEALS AND INTERFERENCES 1 

m. STATUS OF CLAIMS 1 

IV. STATUS OF AMENDMENTS 1 

V. SUMMARY OF CLAIMED SUBJECT MATTER 1 

VI. GROUNDS OF REJECTION TO BE REVIEWED 3 

VIL ARGUMENT 5 

VIIL CLAIM APPENDIX A-1 

IX. EVIDENCE APPENDIX A-8 

X. RELATED PROCEEDINGS APPENDIX A-9 



ii 

H:\PayPal\PAY00-003\Appeal Brief (May 2006).doc 



09/901,954 



I. REAL PARTY IN INTEREST 

The real party in interest is PayPal, Inc., a corporation of the state of 
Delaware, having a place of business at 303 Bryant Street, Mountain View, CA 
94041 . PayPal, Inc. is a wholly owned subsidiary of eBay, Inc., a corporation of 
the state of Delaware, which has a place of business at 2145 Hamilton Avenue, 
San Jose, CA 95125. 

II. RELATED APPEALS AND INTERFERENCES 

Appellant is not aware of any related appeals or interferences. 

III. STATUS OF CLAIMS 

Claims 1-43 are currently pending and have been finally rejected. 
Applicant appeals claims 1-43. 

IV. STATUS OF AMENDMENTS 

There are no currently pending amendments. 

V. SUMMARY OF CLAIMED SUBJECT MATTER 

The present invention relates to methods and apparatus for verifying 
financial instruments or accounts such as credit cards, debit cards, bank accoimts 
and so on. By verifying a financial instrument or account, further assurance can 
be provided that a person attempting to use the instrument or account is 
authorized to do so, and the person can therefore be authorized to use the 
instrument for subsequent transactions. 

According to independent claim 30, a system or apparatus for verifying a 
user's authorization to use a financial account external to the system includes a 
transaction processor configured to initiate transactions involving the account, a 
memory for storing details of the transactions, a user interface for receiving test 
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(e.g., alleged) details of the transactions from the user, and a processor for 
comparing the stored and test details (see FIG. 1). 

According to independent method claims 1, 13, 25 and 27 (and computer 
readable medium claim 29), a system such as that depicted in FIG. 1 performs a 
method of verifying a person's authority to use a financial instrument or account 
(such as a credit card or bank account) by performing any or all of the operations 
described in the following paragraph. 

Information identifying the instrument is received, values are selected for 
one or more transactions, the transactions are initiated by the system on the 
instrument, one or more attributes (or details) of the transactions are stored, the 
person is prompted to confirm the transaction attributes, a set of attributes is 
received from the person, the two collections of attributes are compared and, if 
they match, the system accepts use of the instrument by the person for a 
subsequent transaction (claims 1,13, 25, 27, 29; FIG. 2). 

Independent claim 39 includes elements that may be interpreted under 35 
U.S.C. § 112^6. The apparatus of claim 39 includes means for receiving 
information identifying a financial instrument, transaction means for initiating 
transactions involving the instrument, storage means for storing selected details of 
the transactions, interface means for receiving a confirmation set of details, and 
comparison means for comparing the confirmation details with the stored details. 

The means for receiving and the interface means may correspond to user 
interface 102 of FIG. 1, which can operate on a computing device such as a web 
server, application server or data server (page 5, lines 20-21), and/or a human 
agent or interactive voice recorder (page 5, lines 22-24). The system of FIG. 1 is 
described at page 5, line 17 to page 8, line 8. The transaction means may 
correspond to transaction processor 106 or may be incorporated into some other 
system component (page 6, line 26 to page 7, line 2), and the storage means may 
correspond to database 104. As recited in claim 30, for example, the comparison 
means may correspond to a processor. 
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Thus, when a verification system initiates authorization of a user's 
financial instrument in a claimed embodiment of the invention, a series of 
transactions is performed on the instrument by the system, such as some number 
of debits and/or credits. Some detail or details of the transactions may be set by 
the initiator and are recorded (e.g., amount, type of transaction, merchant identity), 
and the user is invited to confirm those details to verify that he or she owns or has 
control over the instrument. The user retrieves information regarding the 
transactions (e.g., from the organization that issues or maintains the financial 
instrument) and offers it for comparison with the recorded details. If the user's 
proffered details match the recorded details, he or she is permitted to use the 
instrument for subsequent transactions. Page 4, line 17 to page 5, line 3; FIG. 2; 
page 10, line 1 to page 13, line 17. 

Authorization of a financial instrument (or account) may be initiated when 
a user attempts to make a purchase, or may be done prospectively, such as when a 
user identifies an instrument to be used for future transactions. Page 5, lines 4-16. 

Because only someone with legitimate access to and/or control of the 
instrument is likely to have access to details of the transactions that were 
performed in order to verify the instrument, and that person may be required to 
satisfy separate authentication or security procedures in order to obtain those 
details, successful completion of the authentication procedure may decrease the 
risk that the instrument was stolen or that someone is attempting to use the 
instrument illegally. 

VI. GROUNDS OF REJECTIONS TO BE REVIEWED 

Claims 1-43 stand rejected under 35 U.S.C. § 103(a) as being 
unpatentable over U.S. Patent No. 5,903,878, issued to Talati, et al. (hereinafter 
"Talati"). The final office action was mailed December 19, 2005. The 
Examiner's grounds of rejections that Applicant appeals from are as follows. 
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A. That Talati Discloses Storing Details of a Set of Initiated 
Transactions and Receiving Details Proffered by a User for 
Comparison with the Stored Details 

The final rejections assert that a transaction administrator (TA) in Talati 
stores one or more details or attributes of transactions, by storing an originator's 
information (e.g., mother's maiden name, social security number, driver's license 
number), and receives proffered details in the form of answers to a series of 
questions. 

B. That Talati Discloses Comparing the User's Proffered Details 
with the Stored Details and Accepting Use of the Financial 
Instrument Only if the Details Match 

The final rejections assert that a credit authority (CA) in Talati compares 
proffered details with stored details by responding with authorization for a 
transaction if a client confirms transaction validity, and that the CA approves later 
use of a verified financial instrument by approving a client transaction if a client 
confirms the transaction's validity. 

C. That Talati Discloses Selecting Values for a Series of 
Transactions Involving a User's Financial Account 

The final rejections and subsequent advisory action did not address this 
subject matter. 

D. That a Single Entity in Talati Can Perform Applicant's 
Method or Act as Applicant's System 

The final rejections and subsequent advisory action did not address this 

point. 
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VII. ARGUMENT 

Applicant contends that the Examiner's grounds are insufficient bases for 
rejecting the claims of the application, for the reasons stated in this section. First, 
however, a brief summary of the Talati reference is provided. 

Talati is directed to a Method and Apparatus for Electronic Commerce 
(title), and provides a system that includes an originator, a recipient and a 
transaction administrator (TA), each of which is described as a separate party or 
entity (column 2, lines 5 1-67). Briefly, the originator (e.g., a client or purchaser) 
originates an electronic commerce transaction or payment for a transaction 
(column 2, lines 55-60). The recipient (e.g., a merchant or vendor) receives the 
transaction or payment (column 2, lines 60-65). The TA (e.g., a credit card 
authority or financial network) authenticates the originator and recipient, and 
validates transaction contents (column 2, line 65 - colunrn 3, line 3). 

An originator initiates a purchase or payment by sending a transaction to 
the recipient. The transaction includes some details of the purchase, along with a 
unique transaction identifier (UTID) generated by the originator. After receiving 
the transaction, the recipient sends to the TA a payment authorization request that 
includes the UTID. Upon receipt of the payment authorization request, the TA 
validates the originator and the recipient. Validation of the originator requires the 
TA to send to the originator a validation request that includes the UTID. The 
originator extracts the UTID and compares it to a list of generated transaction 
identifiers to determine if the transaction was initiated by the originator, and then 
affirms or denies transaction validity to the TA. (column 3, lines 4-48) 

Applicant asserts that Talati fails to teach or suggest several aspects of 
Applicant's invention. 
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A. That Talati Discloses Storing Details of a Set of Initiated 

Transactions and Receiving Details Proffered by a User for 
Comparison with the Stored Details 

1. Claims 29. 42-43 
Claim 1 is an independent claim to a method of verifying a customer's 
authority to use a financial instrument. Claims 2-12 and 42-43 depend from claim 
1, and claim 29 is an independent computer readable medium claim reflecting the 
method of claim 1 . 

In claims 1 and 29 of the present application, a transaction processor (not a 
customer) initiates one or more transactions using a financial instrument identified 
by a customer, stores one or more attributes of the transactions, and receives 
attributes proffered by the customer to compare with the stored attributes. 

The Examiner cited column 5, lines 33-40 and column 6, lines 25-32 of 
Talati for the proposition that Talati teaches or suggests storing transaction-related 
attributes and the proposition that Talati teaches or suggests receiving a set of 
proffered attributes. However, those sections merely describe the validation of an 
originator, recipient and/or TA through the use of digital signatures, and the 
possible further validation of an originator through a series of originator-specific 
questions. 

The Examiner thus equated Applicant's transaction- specific attributes to 
Talati 's use of non-transaction-related details such as a mother's maiden name, a 
social security number and a driver's license number (Talati, column 5, lines 33- 
40 and column 6, lines 25-32). The types of details recited in Talati are used only 
for the purpose of validating an originator's identity, and therefore necessarily 
relate to the originator , not a transaction . 

The Examiner further stated (page 4 of the final office action) that it is 
well known to store one or more attributes of one or more transactions. However, 
even if this were true in a general sense, the situations and systems in which 
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attributes may be stored further highlight the differences between Applicant's 
invention and the prior art. For example, credit card companies may maintain 
histories of transactions, but the transactions are initiated by the credit card 
holders, not by a system or apparatus for verifying a user's authorization to use a 
credit card or other instrument. Yet further, later elements of Applicant's claims 
specify that successful verification leads to authorization for the user to perform 
later transactions. Credit card companies have already authorized their card 
holders to perform transactions even before they begin to maintain transaction 
histories. Thus, existing systems such as credit card systems do not comport with 
Applicant's claims 1 and 29 (and other claims). 

Claims 4-7 of the present application recite specific examples of 
transaction-related attributes (i.e., amount, merchant identity, number of 
transactions, type of transaction). The types of details recited in Talati teach away 
from these types of attributes by specifying that originator-specific information 
should be used instead. 

2. Claims 13-24 

Claim 13 is an independent claim to a method of verifying a user's 
authorization to use a financial account. Claims 14-24 depend from claim 13. In 
claim 13, a first set of details of transactions involving the account is stored, and a 
test set of details is received for comparison with the stored details. 

These aspects of claim 1 3 were rejected on the same bases as claims 1 and 
29, as discussed above in section VILA. 1 . In particular, the Examiner cited 
column 5, lines 33-40 and column 6, lines 25-32 of Talati for the proposition that 
Talati teaches or suggests storing transaction-related details and the proposition 
that Talati teaches or suggests receiving a set of details. However, those sections 
merely describe the validation of an originator, recipient and/or TA through the 
use of digital signatures, and the possible further validation of an originator 
through a series of originator-specific questions. 
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Applicant asserts that information about an originator as described in 
Talati is fundamentally different from details of transactions that may involve a 
user or originator, and cannot be used for the same purpose. Therefore, Talati 
fails to teach or suggest the storage of transaction details and the receipt of 
proffered details for comparison with the stored details, as recited in claim 13. 

The Examiner further stated (page 4 of the final office action) that it is 
well known to store one or more attributes of one or more transactions. However, 
even if this were true in a general sense, the situations and systems in which 
attributes may be stored further highlight the differences between Applicant's 
invention and the prior art. For example, credit card companies may maintain 
histories of transactions, but the transactions are initiated by the credit card 
holders, not by a system or apparatus for verifying a user's authorization to use a 
credit card or other instrument. Yet further, later elements of Applicant's claims 
specify that successful verification leads to authorization for the user to perform 
later transactions. Credit card companies have already authorized their card 
holders to perform transactions even before they begin to maintain transaction 
histories. Thus, existing systems such as credit card systems do not comport with 
Applicant's claim 13. 

Claims 20-24 recite specific examples of details of a transaction that may 
be stored, such as merchant identity, values of the transactions, types of 
transactions and so on. These types of details are wholly different fi-om the types 
of originator-specific information employed in Talati. 

3. Claims 25-26 
Claim 25 is an independent claim directed to a method of verifying a credit 
card. Claim 26 depends from claim 25. In claim 25, a first set of details of 
transactions involving the credit card is stored, and a test set of details is received 
for comparison with the stored details. 
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These aspects of claim 25 were rejected on the same bases as claims 1 and 
29, as discussed above in section VII.A.l. In particular, the Examiner cited 
column 5, lines 33-40 and column 6, lines 25-32 of Talati for the proposition that 
Talati teaches or suggests storing transaction-related details and the proposition 
that Talati teaches or suggests receiving a set of details from a user. However, 
those sections merely describe the validation of an originator, recipient and/or TA 
through the use of digital signatures, and the possible further validation of an 
originator through a series of originator-specific questions. 

Applicant asserts that information about an originator as described in 
Talati is fundamentally different from details of credit card transactions that may 
involve a user or originator, and cannot be used for the same purpose. Therefore, 
Talati fails to teach or suggest the storage of transaction details and the receipt of 
proffered details for comparison with the stored details, as recited in claim 25. 

Further, the Examiner failed to address an additional feature recited in 
claim 25, wherein the set of details received from a user is received after the 
transactions are completed . In the Talati system, this is impossible because the 
originator (or other party) must be authenticated or validated before a transaction 
can be completed, and thus any transaction/originator details must be received 
during the transaction. This feature of claim 25 shows even more clearly how 
Talati teaches away from Applicant's invention. 

The Examiner fiirther stated (page 4 of the final office action) that it is 
well known to store one or more attributes of one or more transactions. However, 
even if this were true in a general sense, the situations and systems in which 
attributes may be stored fiirther highlight the differences between Applicant's 
invention and the prior art. For example, credit card companies may maintain 
histories of transactions, but the transactions are initiated by the credit card 
holders, not by a system or apparatus for verifying a user's authorization to use a 
credit card or other instrument. Yet further, later elements of Applicant's claims 
specify that successful verification leads to authorization for the user to perform 
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later transactions. Credit card companies have already authorized their card 
holders to perform transactions even before they begin to maintain transaction 
histories. Thus, existing systems such as credit card systems do not comport with 
Applicant's claim 25. 

Claim 26 specifies that the details received from a user for comparison 
v^ith the stored details include an identifier of a merchant involved in a 
transaction. This type of information is far removed from the originator-specific 
information employed in Talati. 

4. Claims 27-28 

Claim 27 is an independent claim directed to a method of verifying a bank 
accoimt. Claim 28 depends from claim 27. In claim 27, a first set of details of 
transactions involving the bank account is stored, and a test set of details is 
received for comparison with the stored details. 

These aspects of claim 27 were rejected on the same bases as claims 1 and 
29, as discussed above in section VILA. 1 . In particular, the Examiner cited 
column 5, lines 33-40 and column 6, lines 25-32 of Talati for the proposition that 
Talati teaches or suggests storing transaction-related details and the proposition 
that Talati teaches or suggests receiving a set of details from a user. However, 
those sections merely describe the validation of an originator, recipient and/or TA 
through the use of digital signatures, and the possible further validation of an 
originator through a series of originator-specific questions. 

Applicant asserts that information about an originator as described in 
Talati is fundamentally different from details of bank account transactions that 
may involve a user or originator, and carmot be used for the same purpose. 
Therefore, Talati fails to teach or suggest the storage of transaction details and the 
receipt of proffered details for comparison with the stored details, as recited in 
claim 27. 
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Further, the Examiner failed to address an additional feature recited in 
claim 27, wherein the set of details received from a user is received after the 
transactions are completed . In the Talati system, this is impossible because the 
originator (or other party) must be authenticated or validated before a transaction 
can be completed, and thus any transaction/originator details must be received 
during the transaction. This feature of claim 27 shows even more clearly how 
Talati teaches away from Applicant's invention. 

The Examiner further stated (page 4 of the final office action) that it is 
well known to store one or more attributes of one or more transactions. However, 
even if this were true in a general sense, the situations and systems in which 
attributes may be stored further highlight the differences between Applicant's 
invention and the prior art. For example, credit card companies may maintain 
histories of transactions, but the transactions are initiated by the credit card 
holders, not by a system or apparatus for verifying a user's authorization to use a 
credit card or other instrument. Yet further, later elements of Applicant's claims 
specify that a user submits test or confirmation details for comparison with the 
stored detail, and that successfiil verification leads to authorization for the user to 
perform later transactions. Credit card companies and banks have already 
authorized their card holders to perform transactions even before they begin to 
maintain transaction histories. Thus, existing systems such as credit card systems 
do not receive test or confirmation details from card holders for comparison with 
stored details, and do not comport with Applicant's claim 27 when viewed as a 
whole. 

Claim 28 specifies that the details received from a user for comparison 
with the stored details include an amount of a transaction. This type of 
information is far removed from the originator-specific information employed in 
Talati. 
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5. Claims 30-38 

Claim 30 is an independent claim directed to a system for verifying a 
user's authorization to use a financial account that is external to the claimed 
system. Claims 31-38 depend from claim 30. The system recited in claim 30 
includes a memory for storing a first set of details of transactions involving the 
account, and a user interface for receiving a test set of details for comparison with 
the stored details. 

The Examiner stated that Talati teaches Applicant's memory by 
mentioning an originator's personal computer that always includes a memory 
(column 4, line 60) and by specifying that the originator generates a list of 
transaction information (column 5, lines 15-19). The Examiner stated that Talati 
teaches Applicant's user interface by mentioning the originator's personal 
computer (column 4, lines 58-65). 

The rejection of claim 30 overlooked the explicit recitation that the user 
interface is "configured to receive a test set of details independent of any 
transaction. . . ." Even if the UTID can be considered a detail of a transaction, 
Talati 's originator receives a UTID as part of a transaction. In fact, the transaction 
cannot be completed until the originator receives and validates the UTID. On a 
more basic note, the mere mention of a personal computer or a processor cannot 
be sufficient to make obvious Applicant's user interface when it is recited as 
having specific functionality. 

The Examiner further stated (page 7 of the final office action) that "a test 
set of details independent of any transaction involving an external financial 
account identified by a user" is well known. Applicant asserts that this statement 
is incorrect for at least two reasons. 

First, systems such as those suggested by the Examiner (e.g., credit card 
issuer, bank) do not receive details of transactions involving external financial 
accounts. If such systems receive details of any transactions, they receive details 
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of transactions of internal financial accounts - the credit cards or accounts they 
manage. 

Second, the transactions for which details are stored and for which test or 
confirmation details are received for comparison in claim 30 are transactions 
initiated by the verification system, not by a user or customer. In contrast, a credit 
card company receives or maintains details of transaction that cardholders initiate. 
And, as further distinction between Applicant's system and the system of Talati 
and other existing systems (e.g., credit card issuers, banks), existing systems do 
not receive test or confirmation sets of details for comparison with stored details 
in order to authorize later use of a user's external financial account. 

6. Claims 39-41 
Claim 39 is an independent claim directed to an apparatus for verifying a 
customer's authority to use a financial instrument. Claims 40-41 depend from 
claim 39. 

Claim 39 was rejected with the same reasoning as claim 30, addressed 
above in section VII.A.5. However, as with the rejection of claim 30, the 
rejection of claim 39 overlooked the explicit recitation that the user interface is 
configured to receive the confirmation set of details "independent of any 
transaction. . . ." Even if the UTID can be considered a detail of a transaction, 
Talati 's originator receives a UTID as part of a transaction. In fact, the transaction 
cannot be completed until the originator receives and validates the UTID. On a 
more basic note, the mere mention of a personal computer or a processor cannot 
be sufficient to make Applicant's user interface obvious. 

The Examiner further stated (page 7 of the final office action) that "a test 
set of details independent of any transaction involving an external financial 
accoimt identified by a user" is well known. Applicant asserts that this statement 
is incorrect for at least two reasons. 
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First, systems such as those suggested by the Examiner (e.g., credit card 
issuer, bank) do not receive details of transactions involving external financial 
accounts. If such systems receive details of any transactions, they receive details 
of transactions of internal financial accounts - the credit cards or accounts they 
manage. 

Second, the transactions for which details are stored and for which test or 
confirmation details are received for comparison in claim 39 are transactions 
initiated by the verification system, not by a user or customer. In contrast, a credit 
card company receives or maintains details of transaction that cardholders initiate. 
And, as further distinction between Applicant's system and the system of Talati 
and other existing systems (e.g., credit card issuers, banks), existing systems do 
not receive test or confirmation sets of details for comparison with stored details 
in order to authorize later use of a user's extemal financial account. 

B. That Talati Discloses Comparing the User's Proffered Details 
with the Stored Details and Accepting Use of the Financial 
Instrument Only if the Details Match 

1. Claims 1-12, 29. 42-43 

Claims 1 and 29 specify that attributes of one or more transactions 
involving a user's financial instrument are proffered by the user and compared to 
stored attributes of one or more transactions. If they match, the financial 
instrument is accepted for a subsequent transaction. 

The Examiner cites column 6, lines 33-36 as proof that Talati discloses 
both limitations, but the cited section merely describes how a credit authority 
(CA) authorizes the current transaction if it is approved and if the originator 
confirms the transaction's validity. Thus, Talati teaches one to validate and 
approve a current transaction, not to validate authority to use a financial 
instrument and approve that instrument for use in a subsequent transaction. 
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Also, as described above in Section VILA, Talati does not collect 
transaction details that are comparable to attributes collected in Applicant's 
claimed methods and apparatus, and therefore cannot compare stored and 
proffered details as required in order to validate one's authority to use a financial 
instrument. 

2. Claims 13-24 

Claim 13 specifies that details of a series of transactions involving a 
financial account are received (from a user) and compared to stored details of the 
transactions, and that if they correspond, the user is authorized to conduct one or 
more subsequent transactions with the same account. 

These aspects of claim 13 were rejected on the same bases as claims 1 and 
29, as discussed above in section VII.B. 1 . In particular, the Examiner cites 
column 6, lines 33-36 as proof that Talati discloses both limitations, but the cited 
section merely describes how a credit authority (CA) authorizes a current 
transaction if it is approved and if the originator confirms the transaction's 
validity. Thus, Talati teaches one to validate and approve a current transaction, 
not to validate authority to use a financial accoimt and approve that account for 
use in a subsequent transaction. 

Also, as described above in Section VILA, Talati does not collect 
transaction details that are comparable to details collected in Applicant's claimed 
methods and apparatus, and therefore caimot compare stored and proffered details 
as required in order to validate one's authority to use a financial account. 

3. Claims 25-26 

Claim 25 specifies that if details of one or more credit card transactions 
received from a user match stored details of the transactions, the user is authorized 
to use the card as a source of funds for a subsequent transaction. 
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These aspects of claim 25 were rejected on the same bases as claims 1 and 
29, as discussed above in section VILB. 1 . In particular, the Examiner cites 
column 6, lines 33-36 as proof that Talati discloses both limitations, but the cited 
section merely describes how a credit authority (CA) authorizes the current 
transaction if it is approved and if the originator confirms the transaction's 
validity. Thus, Talati teaches one to validate and approve a current transaction, 
not to validate authority to use a credit card and approve that credit card for use in 
a subsequent transaction. 

Also, as described above in Section VILA, Talati does not collect 
transaction details that are comparable to details collected in Applicant's claimed 
methods and apparatus, and therefore cannot compare stored and proffered details 
as required in order to validate one's authority to use a credit card. 

4. Claims 27-28 

Claim 27 specifies that if details of one or more bank account transactions 
received from a user match stored details of the transactions, the user is authorized 
to use the account as a source of funds for a subsequent transaction. 

These aspects of claim 27 were rejected on the same bases as claims 1 and 
29, as discussed above in section VII.B. 1 . In particular, the Examiner cites 
column 6, lines 33-36 as proof that Talati discloses both limitations, but the cited 
section merely describes how a credit authority (CA) authorizes the current 
transaction if it is approved and if the originator confirms the transaction's 
validity. Thus, Talati teaches one to validate and approve a current transaction, 
not to validate authority to use a bank account and approve that account for use in 
a subsequent transaction. 

Also, as described above in Section VILA, Talati does not collect 
transaction details that are comparable to details collected in Applicant's claimed 
methods and apparatus, and therefore cannot compare stored and proffered details 
as required in order to validate one's authority to use a bank account. 
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5. Claims 30-38 

Claim 30 recites a processor configured to compare details offered by a 
user to stored details of one or more transactions involving an external financial 
account, after the transactions have been completed. 

In rejecting claim 30, the Examiner stated that Talati discloses Applicant's 
processor at column 5, lines 15-20 as processor 70 (FIG. 5). Even if Talati does 
happen to mention a processor, the processor in Talati is not configured in a 
similar manner. The Examiner recognized (page 7 of the final office action) that 
Talati does not disclose "the test set of details after said transactions have been 
completed," but specified that such a feature is well knovm. 

However, as described above in Section VILA, systems such as those 
suggested by the Examiner (i.e., credit card issuer, bank) do not compare stored 
details of transactions with details received fi"om a user. In particular, there is no 
need for such a system to do so, as it will have already authenticated or validated 
its users before allowing them to conduct transactions. 

Therefore, at best, Talati and other existing systems teach one to confirm a 
transaction identifier of a current transaction in order to authorize that transaction, 
not to confirm details of a past transaction in order to authorize use of a financial 
instrument for subsequent transaction. 

6. Claims 39-41 

Claim 39 recites comparison means for comparing confirmation details 
offered by a customer to stored details of one or more transactions involving a 
financial instrument, wherein the customer is deemed to possess authority to use 
the instrument if the details match. 

Claim 39 was rejected with the same reasoning as claim 30, addressed 
above in section VILB.5. However, no cited portion of Talati appears to suggest 
comparing stored details of transactions with confirmation details that are 
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received independent of any of the transactions, in order to validate the customer's 
authority to use the instrument. 

C. That Talati Discloses Selecting Values for a Series of 
Transactions Involving a User's Financial Account 

Claim 13 recites "selecting values for a series of transactions involving the 
financial account" of a user. Claim 13 was rejected with reference to the same 
rationale as claim 1 , but without addressing this limitation, which is not included 
in claim 1 . 

Talati validates individual electronic commerce transactions in which a 
transaction is generated by a purchaser (Talati abstract; column 2, lines 55-60). 
Thus, terms of a transaction are specified by the purchaser/originator in Talati, not 
by the entity that validates the transaction (e.g., transaction administrator or TA) 
or the entity that accepts a payment (e.g., recipient). This teaches away from 
Applicant's invention, wherein a verification system (e.g., transaction processor) 
constructs and initiates transactions (e.g., FIG. 1; page 6, line 17 to page 7, line 2; 
page 7, lines 14-21; page 11, lines 10-16). 

D. That a Single Entity in Talati Can Perform Applicant's 
Method or Act as Applicant's System 

The independent claims of the present application recite methods or 
systems that are performed or comprise a single entity. In particular, the "system 
for verifying a user's authorization to use an external financial account" of claim 
30 and the "apparatus for verifying a customer's authority to use a financial 
instrument" of claim 39 correspond to system 100 of FIG. 1, which performs steps 
of the methods recited in claims 1,13, 25, 27 and 29. 

In contrast, Talati requires interaction between at least three separate and 
independent entities - the TA, an originator and a recipient. No one entity acting 
alone could (or would be desired to) perform all steps of a method described in 
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the present application, or comprise all elements of a system or apparatus 
described in the present application. 

In particular, the entities that operate in Talati must operate independently 
because Talati is directed to the validation of a single electronic commerce 
transaction involving at least two parties (i.e., the originator and the recipient). 
The TA acts as a trusted entity, operating independently of both parties in order to 
ensure fairness. 

Thus, Talati fails to disclose a method that teaches or suggests all elements 
of Applicant's claimed methods, and also fails to disclose a system that includes 
the elements of Applicant's recited apparatus. 

CONCLUSION 

For the foregoing reasons, Appellant respectfully requests reversal of the 
Examiner's rejections as set forth in the Final Office Action and subsequent 
Advisory Action, and request that the Board direct allov^ance of all pending 
claims of the application. 



Park, Vaughan & Fleming LLP 

39180 Liberty Street, Suite 103 
Fremont, CA 94538 
(510) 790-9960: voice 
(510) 790-9964: facsimile 
electronic mail: dan@parklegal.com 



Respectfully submitted. 



Date: May 9. 2006 



By: 
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VIIL CLAIMS APPENDIX 



1 . Within a system comprising: 

2 a user interface configured to exchange communications with users, and 

a transaction processor coupled to one or more financial systems and configured 
4 to initiate financial transactions through the financial systems, 

a computer-implemented method of verifying a customer's authority to use a 
6 financial instrument, the method comprising: 

initiating one or more transactions using a financial instrument identified 
8 by a customer; 

storing one or more attributes of said one or more transactions; 
10 receiving a set of proffered attributes; 

comparing said proffered attributes to said stored attributes; and 
12 accepting use of the financial instrument by the customer for a subsequent 

transaction if said proffered attributes match said stored attributes. 

2. The method of claim 1, further comprising after said initiating, soliciting 
2 said proffered attributes from the customer. 

3. The method of claim 1, wherein said initiating comprises: 

2 initiating a first transaction involving the financial instrument with a first set of 

attributes; and 

4 initiating a second transaction involving the financial instrument with a second set 

of attributes different from said first set of attributes. 

4. The method of claim 1, wherein said storing attributes comprises storing a 
2 value of a first transaction in said one or more transactions. 

5. The method of claim 1, wherein said storing attributes comprises storing a 
2 merchant identity of a first transaction in said one or more transactions. 



1 

H:\PayPal\PAY0O-O03\Appeal Brief Appendix (May 2006).doc 



09/901,954 



6. The method of claim 1, wherein said storing attributes comprises storing 
the number of said one or more transactions. 

7. The method of claim 1, wherein said storing attributes comprises storing a 
type of one of said one or more transactions. 

8. The method of claim 1, wherein said initiating comprises operating the 
transaction processor to electronically initiate said transactions. 

9. The method of claim 8, wherein said receiving comprises electronically 
receiving said proffered attributes. 

10. The method of claim 1, wherein the financial instrument is a credit card. 

1 1 . The method of claim 1, wherein the financial instrument is a debit card. 

12. The method of claim 1, wherein the financial instrument is a bank account. 

13. A computer-implemented method of verifying a user's authorization to 
use a financial account, comprising: 

receiving from a user information identifying a financial account; 

selecting values for a series of transactions involving the financial account; 

initiating the series of transactions; 

storing a first set of details of said series of transactions; 

receiving a test set of details; 

comparing said test set of details to said first set of details; and 
if said first set of details corresponds to said test set of details, authorizing the user 
to conduct one or more subsequent transactions using the financial account. 

14. The method of claim 13, further comprising soliciting said test set of 
details fi"om the user after said initiating. 



2 

H:\PayPal\PAY0O-OO3\AppeaI Brief Appendix (May 2006).doc 



09/901,954 



15. The method of claim 13, wherein the financial account is a credit card 
2 account. 



16. The method of claim 13, wherein the financial account is a debit card 
2 account. 

17. The method of claim 13, wherein the financial account is a checking 
2 account. 

1 8. The method of claim 13, wherein the financial account is a savings 
2 account. 

19. The method of claim 13, wherein the financial account is a bank account. 

20. The method of claim 13, wherein said first set of details includes a 
2 merchant identity of a first transaction. 

21 . The method of claim 13, wherein said first set of details includes said 
2 selected values. 

22. The method of claim 13, wherein said first set of details includes a type of 
2 a first transaction. 

23. The method of claim 13, wherein said first set of details includes the 
2 number of said transactions. 

24. The method of claim 13, wherein said first set of details includes an 
2 identity of an account involved in said transactions, other than the financial account. 
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25. A computer-implemented method of verifying a credit card in a 
verification system comprising: 

a user interface configured to exchange communications with users, 
a transaction processor coupled to one or more financial systems and configured 
to initiate financial transactions through the financial systems, and 
a database; 

the method comprising: 

receiving from a user an account number and a name identifying a credit 
card the user wishes to use as a source of funds; 

initiating one or more transactions involving the credit card; 

storing a first set of details of said transactions; 

prompting the user to identify details of said transactions; 

after the one or more transactions are completed, receiving from the user a 
second set of details; and 

if said second set of details matches said first set of details, authorizing the 
user to use the credit card as a source of funds for a subsequent transaction. 

26. The method of claim 25, wherein said second set of details includes an 
identifier of a merchant involved in one of said one or more transactions. 

27. A computer-implemented method of verifying a bank account in a 
verification system comprising: 

a user interface configured to exchange communications with users, 
a transaction processor coupled to one or more financial systems and configured 
to initiate financial transactions through the financial systems, and 
a database; 

the method comprising: 

receiving from a user an account number and routing number identifying a 
bank account the user wishes to use as a source of funds; 

initiating one or more transactions involving the bank account; 

storing a first set of details of said transactions; 
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12 prompting the user to identify details of said transactions; 

after the one or more transactions are completed, receiving from the user a 
14 second set of details; and 

if said second set of details matches said first set of details, authorizing the 
16 user to use the bank account as a source of fiinds for a subsequent transaction. 

28. The method of claim 27, wherein said second set of details includes an 
2 amount of one of said one or more transactions. 

29. A computer readable storage medium storing instructions that, when 
2 executed by a computer system, cause the computer system to perform a method of 

verifying a customer's authority to use a financial instrument, the method comprising: 
4 initiating one or more transactions using a financial instrument identified by a 

customer; 

6 storing one or more attributes of said one or more transactions; 

receiving a set of proffered attributes; 
8 comparing said proffered attributes to said stored attributes; and 

accepting use of the financial instrument by the customer for a subsequent 
1 0 transaction if said proffered attributes match said stored attributes. 

30. A system for verifying a user's authorization to use an extemal financial 
2 accoxmt, comprising: 

a transaction processor configured to initiate one or more transactions involving 
4 an extemal financial account identified by a user; 

a memory configured to store a first set of details of said transactions; 
6 a user interface configured to receive a test set of details independent of any 

transaction involving the extemal financial account; and 
8 a processor configured to compare said first set of details and said test set of 

details after said transactions have been completed. 
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3 1 . The system of claim 30, wherein said processor is further configured to 
authorize the user to use the external financial account if said test set of details matches a 
predetermined subset of said first set of details. 

32. The system of claim 30, wherein said transaction processor is coupled to 
an ACH (Automated Clearing House) transaction handler. 

33. The system of claim 30, wherein said transaction processor is coupled to a 
credit card service provider. 

34. The system of claim 33, wherein said credit card service provider is a 
merchant acquirer. 

35. The system of claim 33, wherein said credit card service provider is a 
credit card gateway provider. 

36. The system of claim 30, wherein said transaction processor is configured 
to construct said one or more transactions prior to their initiation. 

37. The system of claim 30, further comprising a computer server for 
operating said user interface. 

38. The system of claim 37, wherein said computer server is further 
configured to construct said one or more transactions prior to their initiation by said 
transaction processor. 

39. An apparatus for verifying a customer's authority to use a financial 
instrument, comprising: 

means for receiving from a customer information identifying a financial 
instrument; 
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transaction means for initiating one or more transactions involving the financial 
instrument; 

storage means for storing selected details of said one or more transactions; 
interface means for receiving a confirmation set of details independent of any 
transaction involving the financial instrument; and 

comparison means for comparing said confirmation set of details to said selected 

details; 

wherein the customer is deemed to have the authority to use the financial 
instrument if said confirmation set of details corresponds to said selected details. 

40. The apparatus of claim 39, further comprising prompting means for 
prompting the customer to provide said confirmation set of details. 

41 . The apparatus of claim 40, wherein said interface means comprises said 
prompting means. 

42. The method of claim 1, wherein said accepting comprises: 
receiving the subsequent transaction, the subsequent transaction identifying a 

destination; and 

transferring fimds from the financial instrument to the destination. 

43. The method of claim 1, wherein said accepting comprises: 
receiving the subsequent transaction, the subsequent transaction identifying a 

source; and 

transferring funds to the financial instrument from the source. 
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IX. EVIDENCE APPENDIX 

NONE 
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X. RELATED PROCEEDINGS APPENDIX 

NONE 
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